[Gradle] Configure transitive dependencies via ComponentMetadataRules #134169

breskeby · 2025-09-04T20:14:36Z

This introduces ComponentMetadataRulesPlugin that contains declarative logic for dealing with transitive dependencies on a per dependency level.
Ulitmately we want more finegrained control over our dependencies without loosing information about transitive dependencies.

The initial list of the applied component metadata rules will be more finegrained over time. Initially this is mostly a reflection of how we brought in dependencies before by basically making the transitive dependencies we identified as required where added as direct dependency.

I started looking through the existing dependencies applyging the following pattern:

if no problematic transitive dependency detected, do not apply any component meta data rule.
if only non group dependencies have been problematic, use ExcludeOtherGroupsTransitiveRule which allows transitive dependencies brought with the same groupId as the parent but excludes all others.
Otherwise exclude all transitive dependencies by applying ExcludeAllTransitivesRule

We will add more specific rules in the future as we see the need to "fix' component metadata of thirdparty dependencies.

This change replaces our plain transitive = false approach for non elasticsearch dependencies

Historically we have solved dealing with transitive dependencies and component metadata in this regard by just ignoring it and bringing in dependencies explicitly. This results in

weaker control what we bring in and why
loose information why a dependency is needed and how its tight ot another dependency on the classpath
transitive behavior differed in different context as we only have applied transitivity

Furthermore the way we have configured transitive = false for each dependency resulted in other problems when using other newer Gradle APIs like test suites.

elasticsearchmachine · 2025-09-04T20:15:02Z

Pinging @elastic/es-delivery (Team:Delivery)

github-actions · 2025-09-04T20:16:09Z

ℹ️ Important: Docs version tagging

👋 Thanks for updating the docs! Just a friendly reminder that our docs are now cumulative. This means all 9.x versions are documented on the same page and published off of the main branch, instead of creating separate pages for each minor version.

We use applies_to tags to mark version-specific features and changes.

Expand for a quick overview

When to use applies_to tags:

✅ At the page level to indicate which products/deployments the content applies to (mandatory)
✅ When features change state (e.g. preview, ga) in a specific version
✅ When availability differs across deployments and environments

What NOT to do:

❌ Don't remove or replace information that applies to an older version
❌ Don't add new information that applies to a specific version without an applies_to tag
❌ Don't forget that applies_to tags can be used at the page, section, and inline level

🤔 Need help?

Check out the cumulative docs guidelines
Reach out in the #docs Slack channel

breskeby · 2025-09-11T11:26:08Z

build-tools-internal/build.gradle

    testImplementation buildLibs.asm
    integTestImplementation buildLibs.asm
    api(buildLibs.snakeyaml)
+    api("org.slf4j:slf4j-api:2.0.6") {


as part of this I tried to get rid of some of the 8 slf4j-api dependencies we use in our build by aligning some versions used in the build tools and third party plugins

breskeby · 2025-09-11T16:51:18Z

.../java/org/elasticsearch/gradle/internal/dependencies/rules/ComponentMetadataRulesPlugin.java

+        // Apache Log4j dependencies
+        // We want to remove log4j-api compile only dependency on biz.aQute.bnd and org.osgi group but
+        // keep other compile only dependencies like spotbugs, errorprone and jspecify
+        components.withModule("org.apache.logging.log4j:log4j-api", ExcludeByGroup.class, config -> {


Preparing for #132166

breskeby · 2025-09-12T06:02:41Z

distribution/packages/build.gradle

+buildscript {
+  dependencies {
+    constraints {
+      classpath "org.slf4j:slf4j-api:2.0.6"


Align slf4j version here so we can get rid of some of the many versions listed in verification metadata

mosche · 2025-09-12T07:34:53Z

Thanks, this is great. Though, I'm not familiar enough to review the implementation.

…elastic#134169) This introduces ComponentMetadataRulesPlugin that contains declarative logic for dealing with transitive dependencies on a per dependency level. Ulitmately we want more finegrained control over our dependencies without loosing information about transitive dependencies. The initial list of the applied component metadata rules will be more finegrained over time. Initially this is mostly a reflection of how we brought in dependencies before by basically making the transitive dependencies we identified as required where added as direct dependency. I started looking through the existing dependencies applyging the following pattern: if no problematic transitive dependency detected, do not apply any component meta data rule. if only non group dependencies have been problematic, use ExcludeOtherGroupsTransitiveRule which allows transitive dependencies brought with the same groupId as the parent but excludes all others. Otherwise exclude all transitive dependencies by applying ExcludeAllTransitivesRule We will add more specific rules in the future as we see the need to "fix' component metadata of thirdparty dependencies. This change replaces our plain transitive = false approach for non elasticsearch dependencies Historically we have solved dealing with transitive dependencies and component metadata in this regard by just ignoring it and bringing in dependencies explicitly. This results in weaker control what we bring in and why loose information why a dependency is needed and how its tight ot another dependency on the classpath transitive behavior differed in different context as we only have applied transitivity Furthermore the way we have configured transitive = false for each dependency resulted in other problems when using other newer Gradle APIs like test suites.

elasticsearchmachine · 2025-09-15T09:56:07Z

💔 Backport failed

Status	Branch	Result
❌	8.19	Commit could not be cherrypicked due to conflicts
✅	9.1
❌	8.18	Commit could not be cherrypicked due to conflicts
❌	9.0	Commit could not be cherrypicked due to conflicts

You can use sqren/backport to manually backport by running backport --upstream elastic/elasticsearch --pr 134169

…elastic#134169) This introduces ComponentMetadataRulesPlugin that contains declarative logic for dealing with transitive dependencies on a per dependency level. Ulitmately we want more finegrained control over our dependencies without loosing information about transitive dependencies. The initial list of the applied component metadata rules will be more finegrained over time. Initially this is mostly a reflection of how we brought in dependencies before by basically making the transitive dependencies we identified as required where added as direct dependency. I started looking through the existing dependencies applyging the following pattern: if no problematic transitive dependency detected, do not apply any component meta data rule. if only non group dependencies have been problematic, use ExcludeOtherGroupsTransitiveRule which allows transitive dependencies brought with the same groupId as the parent but excludes all others. Otherwise exclude all transitive dependencies by applying ExcludeAllTransitivesRule We will add more specific rules in the future as we see the need to "fix' component metadata of thirdparty dependencies. This change replaces our plain transitive = false approach for non elasticsearch dependencies Historically we have solved dealing with transitive dependencies and component metadata in this regard by just ignoring it and bringing in dependencies explicitly. This results in weaker control what we bring in and why loose information why a dependency is needed and how its tight ot another dependency on the classpath transitive behavior differed in different context as we only have applied transitivity Furthermore the way we have configured transitive = false for each dependency resulted in other problems when using other newer Gradle APIs like test suites. (cherry picked from commit a0e6ea1) # Conflicts: # test/fixtures/url-fixture/build.gradle

breskeby · 2025-09-15T10:18:48Z

💚 All backports created successfully

Status	Branch	Result
✅	9.0
✅	8.19
✅	8.18

Questions ?

Please refer to the Backport tool documentation

…#134169) (#134710) This introduces ComponentMetadataRulesPlugin that contains declarative logic for dealing with transitive dependencies on a per dependency level. Ulitmately we want more finegrained control over our dependencies without loosing information about transitive dependencies. The initial list of the applied component metadata rules will be more finegrained over time. Initially this is mostly a reflection of how we brought in dependencies before by basically making the transitive dependencies we identified as required where added as direct dependency. I started looking through the existing dependencies applyging the following pattern: if no problematic transitive dependency detected, do not apply any component meta data rule. if only non group dependencies have been problematic, use ExcludeOtherGroupsTransitiveRule which allows transitive dependencies brought with the same groupId as the parent but excludes all others. Otherwise exclude all transitive dependencies by applying ExcludeAllTransitivesRule We will add more specific rules in the future as we see the need to "fix' component metadata of thirdparty dependencies. This change replaces our plain transitive = false approach for non elasticsearch dependencies Historically we have solved dealing with transitive dependencies and component metadata in this regard by just ignoring it and bringing in dependencies explicitly. This results in weaker control what we bring in and why loose information why a dependency is needed and how its tight ot another dependency on the classpath transitive behavior differed in different context as we only have applied transitivity Furthermore the way we have configured transitive = false for each dependency resulted in other problems when using other newer Gradle APIs like test suites.

…elastic#134169) This introduces ComponentMetadataRulesPlugin that contains declarative logic for dealing with transitive dependencies on a per dependency level. Ulitmately we want more finegrained control over our dependencies without loosing information about transitive dependencies. The initial list of the applied component metadata rules will be more finegrained over time. Initially this is mostly a reflection of how we brought in dependencies before by basically making the transitive dependencies we identified as required where added as direct dependency. I started looking through the existing dependencies applyging the following pattern: if no problematic transitive dependency detected, do not apply any component meta data rule. if only non group dependencies have been problematic, use ExcludeOtherGroupsTransitiveRule which allows transitive dependencies brought with the same groupId as the parent but excludes all others. Otherwise exclude all transitive dependencies by applying ExcludeAllTransitivesRule We will add more specific rules in the future as we see the need to "fix' component metadata of thirdparty dependencies. This change replaces our plain transitive = false approach for non elasticsearch dependencies Historically we have solved dealing with transitive dependencies and component metadata in this regard by just ignoring it and bringing in dependencies explicitly. This results in weaker control what we bring in and why loose information why a dependency is needed and how its tight ot another dependency on the classpath transitive behavior differed in different context as we only have applied transitivity Furthermore the way we have configured transitive = false for each dependency resulted in other problems when using other newer Gradle APIs like test suites. (cherry picked from commit a0e6ea1) # Conflicts: # test/fixtures/url-fixture/build.gradle

…elastic#134169) This introduces ComponentMetadataRulesPlugin that contains declarative logic for dealing with transitive dependencies on a per dependency level. Ulitmately we want more finegrained control over our dependencies without loosing information about transitive dependencies. The initial list of the applied component metadata rules will be more finegrained over time. Initially this is mostly a reflection of how we brought in dependencies before by basically making the transitive dependencies we identified as required where added as direct dependency. I started looking through the existing dependencies applyging the following pattern: if no problematic transitive dependency detected, do not apply any component meta data rule. if only non group dependencies have been problematic, use ExcludeOtherGroupsTransitiveRule which allows transitive dependencies brought with the same groupId as the parent but excludes all others. Otherwise exclude all transitive dependencies by applying ExcludeAllTransitivesRule We will add more specific rules in the future as we see the need to "fix' component metadata of thirdparty dependencies. This change replaces our plain transitive = false approach for non elasticsearch dependencies Historically we have solved dealing with transitive dependencies and component metadata in this regard by just ignoring it and bringing in dependencies explicitly. This results in weaker control what we bring in and why loose information why a dependency is needed and how its tight ot another dependency on the classpath transitive behavior differed in different context as we only have applied transitivity Furthermore the way we have configured transitive = false for each dependency resulted in other problems when using other newer Gradle APIs like test suites.

…taRules (#134169) (#134714) * [Gradle] Configure transitive dependencies via ComponentMetadataRules (#134169) This introduces ComponentMetadataRulesPlugin that contains declarative logic for dealing with transitive dependencies on a per dependency level. Ulitmately we want more finegrained control over our dependencies without loosing information about transitive dependencies. The initial list of the applied component metadata rules will be more finegrained over time. Initially this is mostly a reflection of how we brought in dependencies before by basically making the transitive dependencies we identified as required where added as direct dependency. I started looking through the existing dependencies applyging the following pattern: if no problematic transitive dependency detected, do not apply any component meta data rule. if only non group dependencies have been problematic, use ExcludeOtherGroupsTransitiveRule which allows transitive dependencies brought with the same groupId as the parent but excludes all others. Otherwise exclude all transitive dependencies by applying ExcludeAllTransitivesRule We will add more specific rules in the future as we see the need to "fix' component metadata of thirdparty dependencies. This change replaces our plain transitive = false approach for non elasticsearch dependencies Historically we have solved dealing with transitive dependencies and component metadata in this regard by just ignoring it and bringing in dependencies explicitly. This results in weaker control what we bring in and why loose information why a dependency is needed and how its tight ot another dependency on the classpath transitive behavior differed in different context as we only have applied transitivity Furthermore the way we have configured transitive = false for each dependency resulted in other problems when using other newer Gradle APIs like test suites. (cherry picked from commit a0e6ea1) # Conflicts: # test/fixtures/url-fixture/build.gradle * Fix merge conflicts

…elastic#134169) This introduces ComponentMetadataRulesPlugin that contains declarative logic for dealing with transitive dependencies on a per dependency level. Ulitmately we want more finegrained control over our dependencies without loosing information about transitive dependencies. The initial list of the applied component metadata rules will be more finegrained over time. Initially this is mostly a reflection of how we brought in dependencies before by basically making the transitive dependencies we identified as required where added as direct dependency. I started looking through the existing dependencies applyging the following pattern: if no problematic transitive dependency detected, do not apply any component meta data rule. if only non group dependencies have been problematic, use ExcludeOtherGroupsTransitiveRule which allows transitive dependencies brought with the same groupId as the parent but excludes all others. Otherwise exclude all transitive dependencies by applying ExcludeAllTransitivesRule We will add more specific rules in the future as we see the need to "fix' component metadata of thirdparty dependencies. This change replaces our plain transitive = false approach for non elasticsearch dependencies Historically we have solved dealing with transitive dependencies and component metadata in this regard by just ignoring it and bringing in dependencies explicitly. This results in weaker control what we bring in and why loose information why a dependency is needed and how its tight ot another dependency on the classpath transitive behavior differed in different context as we only have applied transitivity Furthermore the way we have configured transitive = false for each dependency resulted in other problems when using other newer Gradle APIs like test suites. (cherry picked from commit a0e6ea1) # Conflicts: # test/fixtures/url-fixture/build.gradle

…aRules (#134169) (#134712) * [Gradle] Configure transitive dependencies via ComponentMetadataRules (#134169) This introduces ComponentMetadataRulesPlugin that contains declarative logic for dealing with transitive dependencies on a per dependency level. Ulitmately we want more finegrained control over our dependencies without loosing information about transitive dependencies. The initial list of the applied component metadata rules will be more finegrained over time. Initially this is mostly a reflection of how we brought in dependencies before by basically making the transitive dependencies we identified as required where added as direct dependency. I started looking through the existing dependencies applyging the following pattern: if no problematic transitive dependency detected, do not apply any component meta data rule. if only non group dependencies have been problematic, use ExcludeOtherGroupsTransitiveRule which allows transitive dependencies brought with the same groupId as the parent but excludes all others. Otherwise exclude all transitive dependencies by applying ExcludeAllTransitivesRule We will add more specific rules in the future as we see the need to "fix' component metadata of thirdparty dependencies. This change replaces our plain transitive = false approach for non elasticsearch dependencies Historically we have solved dealing with transitive dependencies and component metadata in this regard by just ignoring it and bringing in dependencies explicitly. This results in weaker control what we bring in and why loose information why a dependency is needed and how its tight ot another dependency on the classpath transitive behavior differed in different context as we only have applied transitivity Furthermore the way we have configured transitive = false for each dependency resulted in other problems when using other newer Gradle APIs like test suites. (cherry picked from commit a0e6ea1) # Conflicts: # test/fixtures/url-fixture/build.gradle * Fix merge conflicts * Fix ec2 transitive deps

…elastic#134169) This introduces ComponentMetadataRulesPlugin that contains declarative logic for dealing with transitive dependencies on a per dependency level. Ulitmately we want more finegrained control over our dependencies without loosing information about transitive dependencies. The initial list of the applied component metadata rules will be more finegrained over time. Initially this is mostly a reflection of how we brought in dependencies before by basically making the transitive dependencies we identified as required where added as direct dependency. I started looking through the existing dependencies applyging the following pattern: if no problematic transitive dependency detected, do not apply any component meta data rule. if only non group dependencies have been problematic, use ExcludeOtherGroupsTransitiveRule which allows transitive dependencies brought with the same groupId as the parent but excludes all others. Otherwise exclude all transitive dependencies by applying ExcludeAllTransitivesRule We will add more specific rules in the future as we see the need to "fix' component metadata of thirdparty dependencies. This change replaces our plain transitive = false approach for non elasticsearch dependencies Historically we have solved dealing with transitive dependencies and component metadata in this regard by just ignoring it and bringing in dependencies explicitly. This results in weaker control what we bring in and why loose information why a dependency is needed and how its tight ot another dependency on the classpath transitive behavior differed in different context as we only have applied transitivity Furthermore the way we have configured transitive = false for each dependency resulted in other problems when using other newer Gradle APIs like test suites. (cherry picked from commit a0e6ea1) # Conflicts: # test/fixtures/url-fixture/build.gradle

…taRules (#134169) (#134715) * [Gradle] Configure transitive dependencies via ComponentMetadataRules (#134169) This introduces ComponentMetadataRulesPlugin that contains declarative logic for dealing with transitive dependencies on a per dependency level. Ulitmately we want more finegrained control over our dependencies without loosing information about transitive dependencies. The initial list of the applied component metadata rules will be more finegrained over time. Initially this is mostly a reflection of how we brought in dependencies before by basically making the transitive dependencies we identified as required where added as direct dependency. I started looking through the existing dependencies applyging the following pattern: if no problematic transitive dependency detected, do not apply any component meta data rule. if only non group dependencies have been problematic, use ExcludeOtherGroupsTransitiveRule which allows transitive dependencies brought with the same groupId as the parent but excludes all others. Otherwise exclude all transitive dependencies by applying ExcludeAllTransitivesRule We will add more specific rules in the future as we see the need to "fix' component metadata of thirdparty dependencies. This change replaces our plain transitive = false approach for non elasticsearch dependencies Historically we have solved dealing with transitive dependencies and component metadata in this regard by just ignoring it and bringing in dependencies explicitly. This results in weaker control what we bring in and why loose information why a dependency is needed and how its tight ot another dependency on the classpath transitive behavior differed in different context as we only have applied transitivity Furthermore the way we have configured transitive = false for each dependency resulted in other problems when using other newer Gradle APIs like test suites. (cherry picked from commit a0e6ea1) # Conflicts: # test/fixtures/url-fixture/build.gradle * Fix merge conflicts * Fix dependencies in 8.18

…elastic#134169) This introduces ComponentMetadataRulesPlugin that contains declarative logic for dealing with transitive dependencies on a per dependency level. Ulitmately we want more finegrained control over our dependencies without loosing information about transitive dependencies. The initial list of the applied component metadata rules will be more finegrained over time. Initially this is mostly a reflection of how we brought in dependencies before by basically making the transitive dependencies we identified as required where added as direct dependency. I started looking through the existing dependencies applyging the following pattern: if no problematic transitive dependency detected, do not apply any component meta data rule. if only non group dependencies have been problematic, use ExcludeOtherGroupsTransitiveRule which allows transitive dependencies brought with the same groupId as the parent but excludes all others. Otherwise exclude all transitive dependencies by applying ExcludeAllTransitivesRule We will add more specific rules in the future as we see the need to "fix' component metadata of thirdparty dependencies. This change replaces our plain transitive = false approach for non elasticsearch dependencies Historically we have solved dealing with transitive dependencies and component metadata in this regard by just ignoring it and bringing in dependencies explicitly. This results in weaker control what we bring in and why loose information why a dependency is needed and how its tight ot another dependency on the classpath transitive behavior differed in different context as we only have applied transitivity Furthermore the way we have configured transitive = false for each dependency resulted in other problems when using other newer Gradle APIs like test suites.

breskeby requested a review from a team as a code owner September 4, 2025 20:14

breskeby added >non-issue :Delivery/Build Build or test infrastructure Team:Delivery Meta label for Delivery team auto-backport Automatically create backport pull requests when merged v9.2.0 v9.1.4 v9.0.7 v8.18.7 v8.19.4 labels Sep 4, 2025

breskeby self-assigned this Sep 4, 2025

breskeby changed the title ~~Configure ignoring transitive dependencies via ComponentMetadataRules~~ WIP - Configure ignoring transitive dependencies via ComponentMetadataRules Sep 4, 2025

breskeby marked this pull request as draft September 4, 2025 20:15

breskeby force-pushed the rework-transitive-deps-handling branch 2 times, most recently from 82f2d5f to a5d7913 Compare September 10, 2025 09:38

elasticsearchmachine added v8.18.8 v9.1.5 v8.19.5 v9.0.8 and removed v8.18.7 v9.1.4 v8.19.4 v9.0.7 labels Sep 11, 2025

breskeby changed the title ~~WIP - Configure ignoring transitive dependencies via ComponentMetadataRules~~ Configure ignoring transitive dependencies via ComponentMetadataRules Sep 11, 2025

breskeby force-pushed the rework-transitive-deps-handling branch from fcab26f to 58c5dc5 Compare September 11, 2025 11:11

breskeby changed the title ~~Configure ignoring transitive dependencies via ComponentMetadataRules~~ [Gradle] Configure transitive dependencies via ComponentMetadataRules Sep 11, 2025

breskeby marked this pull request as ready for review September 11, 2025 11:25

breskeby commented Sep 11, 2025

View reviewed changes

breskeby requested review from jozala and mosche September 11, 2025 16:50

breskeby commented Sep 11, 2025

View reviewed changes

breskeby commented Sep 12, 2025

View reviewed changes

more cleanup

11e1d48

breskeby merged commit a0e6ea1 into elastic:main Sep 15, 2025
34 checks passed

breskeby deleted the rework-transitive-deps-handling branch September 15, 2025 09:54

breskeby mentioned this pull request Sep 15, 2025

[9.1] [Gradle] Configure transitive dependencies via ComponentMetadataRules (#134169) #134710

Merged

elasticsearchmachine added the backport pending label Sep 15, 2025

breskeby mentioned this pull request Sep 15, 2025

[9.0] [Gradle] Configure transitive dependencies via ComponentMetadataRules (#134169) #134712

Merged

breskeby mentioned this pull request Sep 15, 2025

[8.19] [Gradle] Configure transitive dependencies via ComponentMetadataRules (#134169) #134714

Merged

breskeby mentioned this pull request Sep 15, 2025

[8.18] [Gradle] Configure transitive dependencies via ComponentMetadataRules (#134169) #134715

Merged

Rassyan mentioned this pull request Sep 15, 2025

Upgrade to log4j 2.25.1 #132166

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[Gradle] Configure transitive dependencies via ComponentMetadataRules #134169

[Gradle] Configure transitive dependencies via ComponentMetadataRules #134169

Uh oh!

breskeby commented Sep 4, 2025 •

edited

Loading

Uh oh!

elasticsearchmachine commented Sep 4, 2025

Uh oh!

github-actions bot commented Sep 4, 2025

When to use applies_to tags:

What NOT to do:

Uh oh!

breskeby Sep 11, 2025

Uh oh!

breskeby Sep 11, 2025

Uh oh!

breskeby Sep 12, 2025

Uh oh!

mosche commented Sep 12, 2025

Uh oh!

Uh oh!

elasticsearchmachine commented Sep 15, 2025

Uh oh!

breskeby commented Sep 15, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

[Gradle] Configure transitive dependencies via ComponentMetadataRules #134169

[Gradle] Configure transitive dependencies via ComponentMetadataRules #134169

Uh oh!

Conversation

breskeby commented Sep 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

elasticsearchmachine commented Sep 4, 2025

Uh oh!

github-actions bot commented Sep 4, 2025

ℹ️ Important: Docs version tagging

When to use applies_to tags:

What NOT to do:

🤔 Need help?

Uh oh!

breskeby Sep 11, 2025

Choose a reason for hiding this comment

Uh oh!

breskeby Sep 11, 2025

Choose a reason for hiding this comment

Uh oh!

breskeby Sep 12, 2025

Choose a reason for hiding this comment

Uh oh!

mosche commented Sep 12, 2025

Uh oh!

Uh oh!

elasticsearchmachine commented Sep 15, 2025

💔 Backport failed

Uh oh!

breskeby commented Sep 15, 2025

💚 All backports created successfully

Questions ?

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

breskeby commented Sep 4, 2025 •

edited

Loading